Method and apparatus to deliver public warning messages

ABSTRACT

A method and apparatus for a wireless transmit receive unit (WTRU) to receive an emergency situation notification. The method and apparatus include the WTRU receiving a paging message with an emergency situation notification, and the WTRU receiving scheduling information in a system information block.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/092,259, filed Nov. 27, 2013, which is continuation of U.S. patentapplication Ser. No. 12/402,005, filed Mar. 11, 2009, issuing as U.S.Pat. No. 8,599,802 on Dec. 3, 2013, which claims the benefit of U.S.Provisional Patent Application No. 61/036,893 filed Mar. 14, 2008, whichare incorporated by reference as if fully set forth herein.

FIELD OF INVENTION

This application is related to wireless communications.

BACKGROUND

The Third Generation Partnership Project (3GPP) has initiated the LongTerm Evolution (LTE) program to bring new technology, new networkarchitecture, new configurations and new applications and services towireless networks in order to provide improved spectral efficiency andfaster user experiences.

There are many man-made and natural emergencies that may causeconsiderable damage over a wide-spread area. Hurricanes, typhoons,tornados, floods, chemical spills and explosions, for example, may causesignificant loss of life and property. While certain governments andcommercial agencies currently provide warnings via siren, radio and/ortelevision, a public warning system incorporated in a wireless transmitreceive unit (WTRU) in an LTE network may increase the probability thata large number of people may be forewarned of these dangers.

FIG. 1 shows an LTE control-plane protocol stack 100 in accordance withthe prior art. The protocol stack 100 may be located in a WTRU 102 andan eNode B (eNB) 120. The stack includes the radio resource control(RRC) 104, 124, the packet data control protocol (PDCP) 106, 126, theradio link control (RLC) 108, 128, the medium access control (MAC) 110,130 and the physical layer (PHY) 112, 132. The non-access stratum (NAS)114, 144 may also reside in the WTRU 102 and a mobility managemententity (MME) 140.

FIG. 2 shows an LTE user-plane protocol stack 200 in accordance with theprior art. The user-plane protocol stack 200 may reside in a WTRU 202and an eNB 222. The user-plane protocol stack 200 may include the PDCP204, 224, the RLC 206, 226, the MAC 208, 218 and the physical layer 210,230.

In an LTE communication system, a WTRU and eNB may share operatingparameters in order to communicate properly. One way for the eNB toinform the WTRU about operating parameters is for the eNB to transmitsystem information to the WTRU. System information is public informationabout how a WTRU communicates with a cell, such as transmissionbandwidth, channel configurations, cell loading and power controlparameters, for example.

There may be a relatively large amount of system information transmittedby an eNB in a cell. Therefore, in order to organize the transmission ofthe system information, the information may be divided into a number ofsystem information blocks (SIBs). The types of the system informationcarried in a particular SIB is constant, but the value of theinformation carried in each SIB is subject to change.

Some SIBs may have the same scheduling requirements, such asperiodicity. There may be more than one system information (SI) messagetransmitted with the same periodicity. Each SIB may contain a set ofrelated SI parameters. Several SIBs have been defined in the prior art,including, for example, a Master Information Block (MIB). The MIB mayinclude a limited number of frequently transmitted parameters. Anotherdefined SIB is SIB type-1. SIB type-1 may contain scheduling informationand may include indicators as to when SI messages are transmitted.System information master (SI-M) and system information 1 (SI-1) arespecial versions of an SI message only carrying a single SIB, namely theMIB and SIB type 1, respectively. The SI-M message is carried on aBroadcast Channel (BCH) while all other SI messages are carried on adownlink shared channel (DL-SCH). The system information carried on BCHis contained in the MIB. All other system information is carried on aDL-SCH.

A paging message may be used to inform a WTRU in RRC_IDLE state about achange in system information. A WTRU in RRC_CONNECTED state may monitora physical downlink control channel (PDCCH) on a periodic basis and at atime specifically defined for this purpose. If a WTRU detects the systeminformation change RNTI (Radio Network Temporary Identifier) on thePDCCH, the WTRU may determine that a system information change willoccur at a next modification period boundary.

The SI-1 message includes a value tag that may indicate if a change hasoccurred in the system information other than the SI-M and SI-1. A WTRUmay use this value tag upon returning from out of coverage to verify ifthe previously acquired system information is still valid. A WTRU mayconsider system information to be valid for at most 6 hours from themoment it was received.

FIG. 3 shows a functional model for a WTRU 300 in accordance with theprior art. The interface between a WTRU 300 and a network is the radiointerface. A WTRU 300 may be divided into a number of domains, thedomains being separated by reference points. Some defined domains arethe universal subscriber identity module (USIM) domain 302 and mobileequipment (ME) domain 304. The ME domain 304 may be further divided intoseveral components showing the connectivity between multiple functionalgroups. These groups may be implemented in one or more hardware devices.An example of such connectivity is the terminal equipment (TE) 306 tomobile termination (MT) 308 interface.

FIG. 4 is a block diagram of physical components 400 mapped to thefunctional diagram 300 of FIG. 3. The universal integrated circuit card(UICC) 402 may be a physical implementation of the USIM 302 of FIG. 3.The remainder of the WTRU 404 may physically represent the MT 308 ofFIG. 3, and a personal computer 406 may physical embody the TE 306 ofFIG. 3.

“Attention” (AT) commands may be used for controlling MT functions andGSM/Universal Mobile Telecommunication System (UMTS) network servicesfrom a terminal equipment (TE) through a terminal adaptor (TA). The useof AT commands assumes an abstract architecture. FIG. 5 shows a blockdiagram of an abstract architecture 500 that may incorporate ATcommands. The architecture 500 includes a TE 502, an MT 506 and a TA 504used as an interface between the TE 502 and the MT 506. The TE 502 maybe a computer, for example. The MT 506 may send MT status messages 508to the TA 504 and receive MT control messages 510 from the TA 504. TheTE 502 may send AT commands 512 to the TA 504 and receive responses 514from the TA 504. As shown in FIG. 5, the TA 504, the MT 506 and the TE502 are separate entities. However, the TA 504 may be integrated underthe MT 506 while the TE 502 is implemented as a separate entity(configuration not shown). Also, the TA 504 may be integrated under theTE 502, with the MT 506 implemented as a separate entity (configurationnot shown). Lastly, the TA 504 and the MT 506 may both be integratedunder the TE 502 as a single entity (configuration not shown).

SUMMARY

A method and apparatus are disclosed for a WTRU to receive an emergencysituation notification. The method and apparatus may include the WTRUreceiving a paging message with an emergency situation notification andthe WTRU receiving scheduling information in a system information block.The WTRU may also receive emergency situation information in anothersystem information block.

BRIEF DESCRIPTION OF THE DRAWINGS

A more detailed understanding may be had from the following description,given by way of example in conjunction with the accompanying drawingswherein:

FIG. 1 shows an LTE control-plane protocol stack in accordance with theprior art;

FIG. 2 shows an LTE user-plane protocol stack in accordance with theprior art;

FIG. 3 shows a functional model for a WTRU in accordance with the priorart;

FIG. 4 is a block diagram of physical components mapped to thefunctional diagram of FIG. 3;

FIG. 5 shows a block diagram of an abstract architecture incorporatingAT commands in accordance with the prior art;

FIG. 6 shows a wireless communication system in accordance with oneembodiment;

FIG. 7 is a functional block diagram of a WTRU and the eNB of thewireless communication system of FIG. 6;

FIG. 8 is a block diagram of WTRU emergency procedures in accordancewith one embodiment; and

FIG. 9 is a block diagram of WTRU emergency procedure in accordance withone embodiment.

DETAILED DESCRIPTION

When referred to hereafter, the terminology “wireless transmit/receiveunit (WTRU)” includes, but is not limited to, a user equipment (UE), amobile station, a fixed or mobile subscriber unit, a pager, a cellulartelephone, a personal digital assistant (PDA), a computer, or any othertype of user device capable of operating in a wireless environment. Whenreferred to hereafter, the terminology “base station” includes, but isnot limited to, a Node-B, a site controller, an access point (AP), orany other type of interfacing device capable of operating in a wirelessenvironment.

FIG. 6 shows a wireless communication system 600 including a pluralityof WTRUs 610 and an eNB 620. As shown in FIG. 6, the WTRUs 610 are incommunication with the eNB 620. Although three WTRUs 610 and one eNB 620are shown in FIG. 6, it should be noted that any combination of wirelessand wired devices may be included in the wireless communication system600.

FIG. 7 is a functional block diagram 700 of the WTRU 610 and the eNB 620of the wireless communication system 600 of FIG. 6. As shown in FIG. 6,the WTRU 610 is in communication with the eNB 620. The WTRU 610 isconfigured to receive system information and system information changenotification from the eNB 620. The WTRU 610 is also configured totransmit and receive RRC messages and information elements. The eNB 620may be configured to transmit, and the WTRU 610 may be configured toreceive and monitor signals on the broadcast control channel (BCCH). TheWTRU 610 may be configured to receive paging messages and other downlinksignaling.

In addition to the components that may be found in a typical WTRU, theWTRU 610 includes a processor 715, a receiver 716, a transmitter 717,and an antenna 718. The WTRU 610 may also include a user interface 721,which may include, but is not limited to, an LCD or LED screen, a touchscreen, a keyboard, a stylus, or any other typical input/output device.The WTRU 610 may also include memory 719, both volatile and non-volatileas well as interfaces 720 to other devices, such as universal serial bus(USB) ports, serial ports and the like. The receiver 716 and thetransmitter 717 are in communication with the processor 715. The antenna718 is in communication with both the receiver 716 and the transmitter717 to facilitate the transmission and reception of wireless data.

In addition to the components that may be found in a typical eNB, theeNB 620 includes a processor 725, a receiver 726, a transmitter 727, andan antenna 728. The receiver 726 and the transmitter 727 are incommunication with the processor 725. The antenna 728 is incommunication with both the receiver 726 and the transmitter 727 tofacilitate the transmission and reception of wireless data.

RRC system information may be utilized to inform WTRUs of emergencysituations. The warning may be distributed to all eNBs in a network. TheRRC layer may place a warning in one or more SIB, or the MIB. The SIB orMIB may include:

-   -   a. notification of an emergency;    -   b. a code or value that is mapped to a particular situation;    -   c. a text message describing the emergency and recommended        action to take;    -   d. a call back phone number for more information;    -   e. an internet address for more information;    -   f. location information of the WTRU or the user;    -   g. information regarding the nearest emergency services        provider, such as hospitals, police stations and the like;    -   h. time; and    -   i. an indicator that a system information update that includes        the emergency information, or a change in emergency information,        is available.

The information may be contained in more than one SIB. For example,information that an emergency exists may be carried in a frequentlyrepeated scheduling unit (SU) such as SU-1. Detailed information may becarried in other SUs.

Alternatively, a fast changing or frequently repeated SIB may be used tocarry all the information required for emergency purposes. A WTRU maymonitor a downlink channel, such as a broadcast channel (BCH) or adownlink shared channel (DL-SCH) at predefined intervals so that theWTRU may act on the emergency information when the fast changing SIB isreceived. Additionally, the WTRU may monitor an MIB and/or schedulinginformation to discover when the SIB for emergency situations will besent. The RRC in the WTRU may acquire the system information related tothe emergency situation. The RRC may then communicate with the NAS andpass the information contained in the emergency situation SIB to the NASfor processing.

At an occurrence of an emergency situation, a WTRU may receive a page toindicate that system information has changed and that emergencyinformation is following. The WTRU may read the updated systeminformation to discover what information is new or changed.

In another embodiment, a ‘paging cause’ may be added to a pagingmessage/record to indicate that a change in system information change isdue to an emergency situation. The WTRU may analyze the paging cause. Ifit finds that system information has changed, the WTRU may read the SIBscontaining the emergency situation information and notify the relevantlayers and applications.

Alternatively, a WTRU may receive a page that indicates that there hasbeen an emergency. The paging cause may include an indication that anemergency exists. Upon receiving the page, the WTRU may read theappropriate SIBs, for example. WTRUs that are camped on cells used foremergency-access only may also listen to paging channels fornotification of public emergencies.

Alternatively, the WTRU may receive a value, for example, N that isincluded in the MIB. When the system frame number (SFN) mod N=0 (orevery Nth frame) the WTRU may read the DL-SCH to discover anyinformation about a warning being transmitted. The location of thewarning SIB may be static when it is transmitted. Alternatively, thelocation of the warning SIB may be predefined so that the WTRU couldappropriately define its reception window. This periodic reading of theSIB could also be performed on occasions when a high risk situation isperceived.

System information resources may be scarce or insufficient to carryextensive text messages that completely describe details of an emergencysituation. The amount of information that is carried over the air duringthe emergency may be reduced, however.

A WTRU may be preloaded or preconfigured with text messages thatcorrespond to particular emergency situations. Examples of the textmessages are shown in TABLE 1.

TABLE 1 Emergency Code Emergency Description 1 Tsunami 2 Earthquake 3Chemical Spill

As shown in TABLE 1, each emergency code may correspond to a particularemergency description. An emergency code “1” may correspond to a tsunamiwarning, a code “2” may correspond to an earthquake warning, and a code“3” may correspond to a chemical spill warning.

Additionally, other forms of preloaded or preconfigured messages, suchas multimedia messages, for example, may be utilized. The preconfiguredmessages may reside on the USIM/Universal Integrated Circuit Card (UICC)of the WTRU or in other non-volatile memory, for example. The WTRU mayreceive and process preconfigured messages, such as Open Mobile Alliance(OMA) messages, for example. Alternatively, RRC or NAS messages may beused to preconfigure the WTRU with emergency codes and theircorresponding textual descriptions.

During an emergency situation, the WTRU may be notified of the emergencysituation code via the RRC system information. The WTRU may then performa lookup using prestored information to determine the text message thatcorresponds to the emergency situation. The WTRU may then display thetext message to the user. The WTRU may also display a multimedia messageafter look-up. This could be user or operator configured. This mayreduce the size of text message information that needs to be transmittedover the air.

The WTRU may receive messages that depend on the specific location ofthe WTRU. For instance, a tsunami alert may have a different message fora WTRU that is close to the shore, versus a WTRU that is one kilometerfrom the shore, versus another WTRU that is five kilometers from theshore or on high ground. Differentiated message behavior for the samewarning may be controlled by a network entity that would manage thedifferent messages delivery to the eNBs, depending on the eNB location.

RRC messages may be enhanced by using information elements to informWTRUs of emergency situations and to convey public warning messages. AWTRU may receive an emergency situation notification from an eNB thatserves the areas that might be affected by the emergency situation. TheRRC layer of the eNB will include the notification of the emergencysituation in an RRC message that includes an information element (IE).The IE may include the emergency information set forth above.

Additional RRC messages may be used that include deterministic ASN.1definitions which may allow the WTRU to parse through the RRC messagesfaster. The IEs that include emergency information may be designated bythe RRC as a high priority and may over-ride the priority of any otherRRC message.

NAS messages may be enhanced by using information elements to informWTRUs of emergency situations and to convey public warning messages. AWTRU may receive an emergency situation notification from an eNB thatserves the areas that might be affected by the emergency situation. TheNAS layer of the eNB may include the notification of the emergencysituation in an NAS message that includes an information element (IE).The IE may include the emergency information set forth above. When theRRC layer receives an NAS emergency message, it may be informed that themessage is of an emergent nature and trigger the RRC to treat themessage with highest priority.

The emergency message may also be an NAS SMS message or a multimediamessaging services (MMS) message. For example, an MMS service could beprovided with a prerecorded message including instructions on what theuser should do. The MMS or SMS may be delivered withmulti-broadcast/multimedia services (MBMS), for example, on a repeatedbasis to ensure that users are reached.

The paging mechanism may be used to notify WTRUs of emergencysituations. Paging may be used to notify WTRUs of terminating,high-priority signaling, with RRC or NAS messages and/or IEs conveyingthe public warning information. Optionally, paging may be used to notifyWTRUs of emergency notification signaling at regular priority, with dataradio bearers conveying the public warning information. The pagingmessage itself conveys the emergency information.

Once a WTRU reads and analyzes a paging cause, subsequent actions maydepend on the RRC state and if the WTRU received the page on a suitablecell. A WTRU in an RRC_IDLE state may first establish an RRC connectionby performing a random access procedure on the random access channel(RACH). However, if the WTRU is in RRC_CONNECTED, it may not need toperform the random access procedure on the RACH. After the random accessprocedure is completed, a WTRU may monitor the physical downlink controlchannel (PDCCH) for downlink resource assignment.

In the downlink, the WTRU may receive an emergency notification on asignaling radio bearer (SRB) as an NAS message or an RRC messages. TheWTRU may also receive the emergency notification on a data radio bearer(DRB) as a user data application.

If the emergency notification is received as an RRC message, it may becarried on an SRB designed for high priority messages, for example,SRB2. Other SRBs may be used as well. If the emergency notification issent as NAS messages, an SRB designed to carry NAS messages, such asSRB1, for example, may be used. The use of other SRBs, such as SRB2 orSRB0 is also possible.

If the emergency notification is sent on a DRB as data, the highestpriority DRB may be used so that the highest priority DRB may bescheduled before all other DRBs with no bit-rate constraint. The WTRUmay receive the downlink transmissions on the allocated resources andforward the emergency notification message to the relevant upper layer.

There may be times when a WTRU may not be allowed to register in aparticular system. However, for an emergency situation, a system mayaccept registration for the emergency notification only. This may occurduring an “emergency period”. During the emergency period the WTRU mayremain registered so that the WTRU may be paged. This may require theuse of the Mobility Management Entity (MME). If, under normalcircumstances a WTRU is not allowed to register, it may performregistration or attachment to the network whereby theregistration/attachment message indicates that the reason is to be ableto receive emergency notification messages.

The allowance of a normally barred WTRU to register may be indicated onthe system information of the network. The WTRU may receive, forexample, an indicator, that may be as small as one bit, to inform theWTRU whether it is allowed to register to receive an emergencynotification. The WTRUs may register based on the indicator in thesystem information. Therefore, for example, a WTRU that has not yetperformed registration/attachment may perform one or more of theprocedures related registration/attachment based on the WTRU readingsystem information indicating that an emergency notification may becommunicated.

Once the WTRU is notified of a public warning message, the WTRU mayprepare an emergency number to dial and may prompt the user. Suchenhanced functionality may help the user avoid panic. FIG. 8 is a blockdiagram of WTRU emergency procedure 800 in accordance with oneembodiment. An emergency message 802 is received at the WTRU 804. TheWTRU MT 806 receives the emergency notification message. The message mayinclude a phone number or an Internet address to contact. The WTRU MT806 conveys the message 802 to the WTRU TE 808 via primitives or ATcommands, such as an ‘MT status’ and ‘response’ primitive or AT command,for example. The primitive or AT command may indicate that an emergencyhas occurred and that a warning is required. The primitive or AT commandmay also provide details on the emergency, with a phone number or anInternet address to contact for further information.

Upon receiving the primitive or AT command, a first application 810 mayrun on the TE 808 and warns the user by playing a special sound, ring orbeep that indicates to the user that an emergency message has beenreceived. The warning sound may be at a very high volume.

A second application 812 that runs on the TE 808 may look up anappropriate emergency phone number to be dialed, such as a numberreceived with the warning message or a preconfigured phone number suchas 911, for example. The second application 812 may prompt the user todial the number. For example, the application could display a message onthe display screen of the WTRU that prompts a user to dial 911. If theuser confirms the dial request, the second application 812 will instructthe WTRU MT 806, using an AT command, to dial 911.

Furthermore, once the emergency notification 802 is received, the WTRU804 may run a third application 814 that prepares a message thatcontains the WTRUs position information. The message may be populatedusing a GPS, cell/tracking area info or any other positioningapplication. Once the WTRU MT 806 conveys the emergency message 802 tothe WTRU TE 808, the third application 814 that may run on the TE 808,creates a message that contains the WTRU's position information, such ascoordinates, for example. The position information may be obtained froma GPS device, cell/tracking area info or any other positioningapplication. The third application 814 may prompt the user forinstruction. The third application 814 may use AT commands to instructthe WTRU MT 806 to send a message containing the WTRU's positioninformation. The message may be sent over an SRB as an RRC or NASmessage, for example, or over a DRB. The WTRU may also use an assistedGPS, based in the control plane or secure user plane (SUPL).

Once the emergency notification is received by the WTRU, the WTRU maygenerate and sends a tracking area update (TAU) message to an eNB. Thisoperation may be done within the WTRU MT 806. The TAU message mayinclude, as a ‘cause’, an indication that the WTRU transmitted the TAUin response to an emergency situation message. The network may utilizethe TAU to determine which cells or areas the WTRU is located in, and todetermine the WTRU's position. The network may then send more specificor follow-up messages in addition to the original warning messagetargeting specific WTRUs in specific cells.

A WTRU may utilize a higher access priority, such as higher RACHpriority or higher access class (AC), for example, when performing anaccess procedure in any of the situations associated with receiving theemergency situation notification, including, for example, preparing anumber to dial, sending position information, sending a TAU, or otheractions related to receiving the emergency notification. This will allowthe prioritization of those actions by the WTRU.

FIG. 9 is a block diagram of WTRU emergency procedure 900 in accordancewith one embodiment of the present invention. After receiving theemergency situation notification, the WTRU may reselect 902 to adifferent cell or different radio access technology (RAT). The WTRU mayautonomously reselect to a cell offering circuit switched (CS) services.The WTRU may also suspend procedures 904. The WTRU may suspend allprocedures, or may suspend a subset of all procedures. The WTRU may thenprioritize the access class 906 of the next or any new RRC connectionrequests initiated by the user. The user may be given the option ofprioritizing a connection as an emergency call. This may allow the userto communicate with destinations other than emergency destinations. Thisoption may only be available to the user when the terminal is aware ofan ongoing emergency and may limit the user to a certain number ofnon-emergency contacts.

During a public emergency, the network may wish to conserve radioresources by reserving usage of bandwidth to emergency calls, internetaccess and the like. To achieve this, the network may interrupt ongoingconnections deemed to be of a lower priority, such as a high speed videodownload, for example. The network may interrupt the ongoing service bysending an NAS/RRC message dedicated to service interruption in anemergency situation. Optionally, the network may send an IE in anNAS/RRC message. The message may indicate to the terminal that the causefor the connection to be dropped is an ongoing emergency. The messagemay provide further information about the emergency. This procedure maybe utilized by the network to reject any new RRC CONNECTION REQUEST/NASSERVICE REQUEST that requests QoS for a service that is incompatiblewith those needed for an emergency call or some other basic service,such as internet access, for example. The network may also interrupt theongoing service by suspending, tearing down or releasing radio bearersthat are deemed to be low priority due to the emergency situation.

In the event of an ongoing emergency situation, it may be desirable torestrict the number of connection requests to only those for emergencyservices or other service classes meeting the access restrictions. Whena user requests a service that is not an emergency call the TE, withassistance from the MT, may remind the user that a public emergency isongoing. The TE may inform the user that the session may not be setupand/or may be rejected. This may be done using an application. MTprimitives and AT commands may achieve this. The TE may request that theuser confirm his/her intention to proceed with the connection request.The TE may choose not to perform the connection request.

Although features and elements are described above in particularcombinations, each feature or element may be used alone without theother features and elements or in various combinations with or withoutother features and elements. The methods or flow charts provided hereinmay be implemented in a computer program, software, or firmwareincorporated in a computer-readable storage medium for execution by ageneral purpose computer or a processor. Examples of computer-readablestorage mediums include a read only memory (ROM), a random access memory(RAM), a register, cache memory, semiconductor memory devices, magneticmedia such as internal hard disks and removable disks, magneto-opticalmedia, and optical media such as CD-ROM disks, and digital versatiledisks (DVDs).

Suitable processors include, by way of example, a general purposeprocessor, a special purpose processor, a conventional processor, adigital signal processor (DSP), a plurality of microprocessors, one ormore microprocessors in association with a DSP core, a controller, amicrocontroller, Application Specific Integrated Circuits (ASICs), FieldProgrammable Gate Arrays (FPGAs) circuits, any other type of integratedcircuit (IC), and/or a state machine.

A processor in association with software may be used to implement aradio frequency transceiver for use in a wireless transmit receive unit(WTRU), user equipment (UE), terminal, base station, radio networkcontroller (RNC), or any host computer. The WTRU may be used inconjunction with modules, implemented in hardware and/or software, suchas a camera, a video camera module, a videophone, a speakerphone, avibration device, a speaker, a microphone, a television transceiver, ahands free headset, a keyboard, a Bluetooth® module, a frequencymodulated (FM) radio unit, a liquid crystal display (LCD) display unit,an organic light-emitting diode (OLED) display unit, a digital musicplayer, a media player, a video game player module, an Internet browser,and/or any wireless local area network (WLAN) or Ultra Wide Band (UWB)module.

What is claimed:
 1. A method implemented by a wireless transmit receiveunit (WTRU), the method comprising: the WTRU receiving a paging messagewhile the WTRU is in one of a radio resource control (RRC) CONNECTEDstate or an RRC IDLE state, the paging message comprising an emergencynotification indication; the WTRU receiving a system information block(SIB) type-1 in response to receiving the paging message including theemergency notification indication, wherein the SIB type-1 comprisesscheduling information for at least one additional SIB, and the at leastone additional SIB comprises emergency information associated with theemergency notification indication; the WTRU receiving the at least oneadditional SIB in accordance with the scheduling information included inthe SIB type-1; and the WTRU outputting at least one of an audio orvisual alert in response to receiving the emergency information.
 2. Themethod as in claim 1, wherein the WTRU receiving the SIB type-1 isperformed in response to the emergency notification indication beingincluded in the paging message.
 3. The method as in claim 1, wherein theSIB type-1 is transmitted by an evolved Node-B (eNB) at a periodicitythat is greater than a periodicity used for transmitting other types ofSIBs.
 4. The method as in claim 1, wherein the at least one additionalSIB comprises at least two SIBs, a first SIB of the at least two SIBscomprises information regarding a type of emergency, and a second SIB ofthe at least two SIBs comprises a text message describing a recommendaction to take regarding the emergency.
 5. The method as in claim 1,wherein the emergency information included in the at least oneadditional SIB comprises an indication of a type of emergency.
 6. Awireless transmit receive unit (WTRU) comprising: a receiver configuredto receive a paging message while the WTRU is in one of a radio resourcecontrol (RRC) CONNECTED state or an RRC IDLE state, the paging messagecomprising an emergency notification indication; a processor configuredto: acquire, via the receiver, a first system information block (SIB) inresponse to the paging message including the emergency notificationindication, wherein the first SIB comprises scheduling information forat least one additional SIB, acquire, via the receiver, the at least oneadditional SIB in accordance with the scheduling information, the atleast one additional SIB comprising emergency information associatedwith the emergency notification indication; and a display configured todisplay a visual alert based on the emergency information.
 7. The WTRUas in claim 6, wherein the first SIB corresponds to a long termevolution SIB type-1.
 8. The WTRU as in claim 7, wherein the SIB type-1is transmitted by an evolved Node-B (eNB) at a periodicity that isgreater than a periodicity used for transmitting other types of SIBs. 9.The WTRU as in claim 6, wherein the at least one additional SIBcomprises at least two SIBs, a first SIB of the at least two SIBscomprises information regarding a type of emergency, and a second SIB ofthe at least two SIBs comprises an emergency description.
 10. The WTRUas in claim 6, wherein the emergency information associated with theemergency notification indication comprises an indication of a type ofemergency.
 11. The WTRU as in claim 6, further comprising a speakerconfigured to output a sound at high volume based on the WTRU receivingthe emergency information.
 12. The WTRU as in claim 6, wherein theprocessor is configured to continue to monitor a physical downlinkcontrol channel (PDCCH) without performing a random access channel(RACH) procedure after receiving the paging message based on the WTRUbeing in the RRC CONNECTED state when the paging message is received.13. The WTRU as in claim 6, wherein the processor is configured toperform a random access channel (RACH) procedure after receiving thepaging message when the WTRU is in the RRC IDLE state when the pagingmessage is received.
 14. A wireless transmit receive unit (WTRU)comprising: a receiver configured to receive a paging message while theWTRU is in one of a radio resource control (RRC) CONNECTED state or anRRC IDLE state, the paging message comprising an emergency notificationindication; a processor configured to: acquire, via the receiver, afirst system information block (SIB) in response to the paging messageincluding the emergency notification indication, wherein the first SIBcomprises scheduling information for at least a second SIB, acquire, viathe receiver, the second SIB in accordance with the schedulinginformation, the second SIB comprising emergency information associatedwith the emergency notification; and a speaker configured to output asound based on the WTRU receiving the emergency information.
 15. TheWTRU as in claim 14, wherein the first SIB corresponds to a long termevolution SIB type-1.
 16. The WTRU as in claim 15, wherein the SIBtype-1 is transmitted by an evolved Node-B (eNB) at a periodicity thatis greater than a periodicity used for transmitting other types of SIBs.17. The WTRU as in claim 14, wherein the emergency informationassociated with the emergency notification indication comprises anindication of a type of emergency.
 18. The WTRU as in claim 14, furthercomprising a display configured to display a text message associatedwith the emergency information.
 19. The WTRU as in claim 14, wherein theprocessor is configured to continue to monitor a physical downlinkcontrol channel (PDCCH) without performing a random access channel(RACH) procedure after receiving the paging message based on the WTRUbeing in the RRC CONNECTED state when the paging message is received.20. The WTRU as in claim 14, wherein the processor is configured toperform a random access channel (RACH) procedure after receiving thepaging message when the WTRU is in the RRC IDLE state when the pagingmessage is received.